I like the idea of containerizing the build process. How do you envision this being used? Would Makefile be modified to build and run the container?

Hi @saad-ali,

This is just a short-cut for now. Ultimately, even if the Travis-CI build went to sudo mode to utilize this process, we'd still want to employ dep to manage the protobuf dependency to make sure it and its dependency graph are pinned at known versions.

So, in other words, the first step is merging #113, then building on that with this to have the option to do a Docker build with known dependencies and required tools, such as protoc.

Hi @saad-ali,

Additionally, I'd likely publish csi/spec as an executable image rather than what it is now, a way to build the current spec.md into the generated output. As an executable image it would simply consume spec.md and emit the desired output, ex. csi.proto, csi.pb.go, etc. I started down this path in fact except that the default golang Docker image doesn't have the unzip command in it, and I could not use it to get and inflate the protoc zip file needed to do the one-liner.

However, even as an executable image, we'd still need dep to manage the Go dependency graph as no one wants to use go get to get random dependencies based on HEAD revisions. So if we need dep and its Gopkg files regardless, why not use the ones in #113 as a starting point?

Would Makefile be modified to build and run the container?

Ideally the Makefile would not require a container.

Hi @cpuguy83 and @saad-ali,

Ideally the Makefile would not require a container.

Exactly. I'm working on an update to this that will be what we want (I think).

Replaced by #181